Previously, it was not possible to create a workspace for a private project. To clone a private project, you could only authenticate yourself after you created the workspace.

With GitLab 16.4, you can create a workspace for any public or private project. When you create a workspace, you get a personal access token to use with the workspace. With this token, you can clone private projects and perform Git operations without any additional configuration or authentication.

Allowing developers access to Kubernetes clusters requires either developer cloud accounts or third-party authentication tools. This increases the complexity of cloud identity and access management. Now, you can grant developers access to Kubernetes clusters using only their GitLab identities and the agent for Kubernetes. Use traditional Kubernetes RBAC to manage authorizations within your cluster.

Together with the OIDC cloud authentication offering in GitLab pipelines, these features allow GitLab users to access cloud resources without dedicated cloud accounts without jeopardizing security and compliance

In this first iteration of cluster access, you must manage your Kubernetes configuration manually. Epic 11455 proposes to simplify setup by extending the GitLab CLI with related commands.

When reviewing a list of dependencies, it is important to have an overall view. Managing dependencies at the project level is problematic for large organizations that want to audit their dependencies across all their projects. With this release, you can see all dependencies at the project or group level, including subgroups. This feature is now available by default.

Some vulnerabilities need to be addressed in bulk. Whether they are false positives or no longer detected, it’s important to minimize the noise and triage vulnerabilities with ease. With this release you can bulk change the status and make a comment for multiple vulnerabilities from a group or project Vulnerability Report.

Some organizations want to give their security teams the least amount of access necessary so they can adhere to the Principle of Least Privilege. Security teams should not have access to write code updates, but they must be able to approve merge requests, view vulnerabilities, and update a vulnerability’s status.

GitLab now allows users to create a custom role based on the access of the Reporter role, but with the added permissions of:

• Viewing the dependency list (read_dependency).
• Viewing the security dashboard and vulnerability report (read_vulnerability).
• Approving a merge request (admin_merge_request).
• Changing status of a vulnerability (admin_vulnerability).

We plan to remove the ability to change the status of a vulnerability from the Developer role for all tiers in 17.0, as noted in this deprecation entry. Feedback on this proposed change can be shared in issue 424688.

Fast-forward merge is a common and popular merge method which avoids merge commits, but requires more rebasing. Separately, Merge Trains are a powerful tool to help with some of the greater challenges related to frequently merging into the main branch. Unfortunately, before this release you could not use merge trains and fast-forward merge together.

In this release, self-managed admins can now enable both Fast-forward merge and merge trains in the same project. You can get all the benefits of merge trains, which ensure all your commits work together before merging, with the cleaner commit history of fast forward merges!

To enable the Fast-forward merge trains, locate the feature flag fast_forward_merge_trains_support, which has been disabled by default, and enable it.

In GitLab 15.9 we announced the deprecation of older versions of JSON web tokens in favor of id_token. Unfortunately, jobs had to be modified individually to accommodate this change. To enable a smooth transition to id_token, beginning from GitLab 16.4, you can set id_tokens as a global default value in .gitlab-ci.yml. This feature automatically sets the id_token configuration for every job. Jobs that use OpenID Connect (OIDC) authentication no longer require you to set up a separate id_token.

Use id_token and OIDC to authenticate with third party services. The required aud sub-keyword is used to configure the aud claim for the JWT.